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Description 

GEOGRAPHIC AREA MULTIPLE SERVICE 

CARD SYSTEM 

Cross Reference to Related Applications 

[0001] This application is a continuation in part of U.S. Serial No. 
09/764,688 filed on January 16, 2001 and entitled "Multi- 
ple-Service Card System" (which itself claims benefit from 
U.S. Provisional Patent Application Serial No. 60/177,530, 
filed January 21, 2000) and also claims priority to U.S. 
Provisional Patent Application Serial No. 60/482,644, filed 
June 26, 2003, all of which are hereby incorporated by 

reference. 
Field of Invention 

[0002] The present invention generally relates to credit card and 
transportation card services and, more particularly, to a 
system for providing a single card that functions as both a 
credit card, for gaining access to credit services provided 
by a primary party, and a transportation card, for gaining 
access to one or more transportation system which is ad- 



ministered by a service partner. 
Background of Invention 

[0003] | n today's world, there is a wide variety of services that are 
available to a consumer where access to the services de- 
pends upon the consumer's possession of a card or code. 
For example, some of the services to which a typical con- 
sumer may gain access by possessing a card, include en- 
try to a transportation service (e.g., public transportation), 
access to a membership club, entry to an access-re- 
stricted location, access to credit services, telephone sys- 
tem use, and accrual of loyalty rewards/incentives such as 
frequent flier miles or grocery store discounts and re- 
bates. 

[0004] D ue t0 the desirability of such services, consumers in to- 
day's world typically carry a wide array of cards in their 
wallets and purses. The cards consumers now carry in- 
clude, among others, credit cards, driver's licenses, sub- 
way access cards, bus cards, train passes, frequent flier 
cards, professional registration cards, retailer loyalty 
cards, and security-related restricted-access cards. Typi- 
cally, each of these consumer cards contains information 
about the specific user or consumer, information about 
the service or benefit provider and information defining 



the memberships or services to which the consumer is 
entitled by virtue of his or her possession of the card. The 
information concerning the consumer may include pho- 
tographs, signatures, fingerprints, biometrics and other 
information that identifies or describes the consumer. In- 
formation regarding the identity of the service provider, 
and the associated services to which the consumer is enti- 
tled, may be readily ascertained by reading the face of the 
card, may be encoded or accessed by using the card. In- 
formation may be incorporated onto the cards through a 
variety of means including imprinting, punching, laminat- 
ing, embossing, bar encoding, magnetic stripe encoding, 
and even affixation or incorporation of micro-chips. 
[0005] Unfortunately, due to the proliferation of memberships 
and services currently available from diverse service 
providers, the quantity of cards that average consumers 
carry has become unreasonably and unnecessarily bur- 
densome. For example, on a single shopping trip, a typi- 
cal consumer may carry a drivers license to drive their 
motor vehicle to the merchant's location, a transportation 
card to obtain access to public transportation, a member- 
ship card to obtain access to the merchant's exclusive 
membership shopping club (e.g., Costco), a calling card to 



make phone calls during the shopping trip, and a credit 
card to obtain credit services to facilitate the purchase of 
goods from the merchant. Yet, it can be cumbersome and 
uncomfortable to carry all these necessary cards in one's 
wallet, pocket or purse. 
[0006] Thus, it would be advantageous to decrease the volume of 
cards that a consumer must carry while retaining the con- 
sumer's access to the full array of services provided by the 
diversity of service providers. Simultaneous with the de- 
sire to reduce the volume of cards, there is an evident 
need to increase the information carrying capacity or in- 
formation accessibility using such consumer cards. Fur- 
thermore, the prior art attempts at reducing the quantity 
of cards a consumer must carry are typically aimed at 
modifying the cards, rather than modifying the processes 
and systems employed by the individual benefit providers, 
such that the consumer may continue to enjoy benefit 
from multiple providers. In fact, none of the methods or 
systems for providing a multiplicity of services through a 
single card that are known in the art involve substantial 
administrative cooperation between distinct service 
providers. 

[0007] Furthermore, it has become apparent that consumers who 



seek access to a particular set of services from one service 
provider are more likely to desire access to a second set 
of services from a distinct class of service providers. For 
example, it stands to reason that consumers who access a 
transportation system are likely to desire credit services 
during their trip to a merchant. Therefore, it would be ad- 
vantageous for providers of distinct services such as 
credit services and transportation services to cooperate to 
offer a single card that provides consumers with access to 
the services of the currently separate and distinct cards. 
By doing so, a primary party provider of credit services 
and a partnering transportation organization can encour- 
age use of their respective services while providing a syn- 
ergistic administrative benefit to themselves and their 
consumers. 

[0008] Moreover, in addition to credit services and transportation 
services, the cards may be used for loyalty programs. Be- 
cause numerous loyalty programs exist, businesses have a 
difficult time differentiating their loyalty programs from 
other loyalty programs on the market. Moreover, many 
consumers often travel for work related reasons, so they 
may not desire to use their loyalty points to travel to dis- 
tant cities or distant countries. Rather, many consumers 



enjoy the services of their "hometown" region, including 
local restaurants, local theaters, local sporting activities 
and other events. At the same time, marketers have begun 
to understand that many consumers develop a strong 
pride, emotional affinity and loyalty to the geographic re- 
gion where they live. As such, a long-felt need exists for a 
multiple service card which includes a loyalty program 
which rewards consumers for purchases in certain local 
geographic areas and which enables consumers to utilize 

their loyalty points in similar local geographic areas. 
Summary of Invention 

[0009] The present invention facilitates providing consumers with 
the services of multiple cards or accounts while allowing 
consumers to carry a single card, transponder, code and/ 
or other access device. The card may include one or more 
magnetic stripes. The invention enables a single card to 
function in multiple modes, for example, as both a credit 
card and a separate service partner's transportation card. 
The invention also provides methods for opening new ac- 
counts, methods for accomplishing card replacement, 
methods for canceling a transportation service, methods 
for canceling a primary party account, and methods for 
transferring an account to a different service partner ac- 



count. The multiple-service card may include any combi- 
nation of demographic information, a barcode, magnetic 
stripes, biometric and a photo in addition to standard 
credit card information. 

[0010] Because the card may access combined services such as 
financial transaction services and transportation services, 
the system may facilitate charging the financial account 
for the transportation services. The system may allow the 
consumer to use loyalty points or geographic based loy- 
alty points to pay for the transportation services. The sys- 
tem may also limit the use of certain loyalty points based 
upon the geographic area for certain transportation ser- 
vices in certain geographic areas. 

[0011] More specifically, the system includes a multiple service 
card configured to access financial services provided by a 
provider of financial services via a financial account, 
wherein the financial account is associated with a con- 
sumer; and, provide the same consumer access to a 
transportation vehicle (e.g., bus, subway and train) pro- 
vided by a service partner. The invention also includes a 
method for facilitating obtaining access to a transporta- 
tion vehicle by using a multiple service card to charge fees 
related to the access to an account associated with a 



provider of credit services. The method includes: provid- 
ing a multiple service card to a consumer, wherein the 
card provides access to a transportation vehicle and facili- 
tates financial transactions; maintaining, by the provider 
of credit services, a financial account corresponding to the 
multiple service card of the consumer; receiving a request 
to charge an amount to obtain access to the transporta- 
tion vehicle from the service partner; determining if the 
requested service partner is affiliated with the provider of 
credit services; adjusting the financial account based upon 
the request and the amount; and, crediting an account of 

the service partner. 
Brief Description of Drawings 

[0012] Additional aspects of the present invention will become 
evident upon reviewing the non-embodiments described 
in the specification and the claims taken in conjunction 
with the accompanying figures, wherein like numerals 
designate like elements, and: 

[0013] pig. 1 is a schematic diagram of an exemplary system for 
providing a multiple-service card; 

[0014] pig. 2a is a flowchart of a portion of an exemplary new ac- 
count process, complementing fig. 2b, in accordance with 
the present invention; 



[0015] pig. 2b is a flowchart of a portion of an exemplary new 
account process, complementing Fig 2a, in accordance 
with the present invention; 

[0016] pig. 3a is a flowchart of a portion of an exemplary multi- 
ple-service card replacement process, complementing Fig. 
3b, in accordance with the present invention; 

[0017] Fig. 3b is a flowchart of a portion of an exemplary multi- 
ple-service card replacement process, complementing Fig. 
3a, in accordance with the present invention; 

[0018] Fig. 4 is a flowchart of an exemplary multiple-service card 
service partner cancellation process in accordance with 
the present invention; and 

[0019] Fig. 5a is a flowchart of a portion of an exemplary multi- 
ple-service card primary party cancellation process, com- 
plementing Fig. 5b, in accordance with the present inven- 
tion; and, 

[0020] Fig. 5b is a flowchart of a portion of an exemplary multi- 
ple-service card primary party cancellation process, com- 
plementing Fig. 5a, in accordance with the present inven- 
tion. 

Detailed Description 

[0021] Th e present invention may be described herein in terms of 
functional block components, screen shots, optional se- 



lections, and various processing steps. It should be ap- 
preciated that such functional blocks may be realized by 
any number of hardware and/or software components 
configured to perform the specified functions. For exam- 
ple, the present invention may employ various integrated 
circuit components, e.g., memory elements, processing 
elements, logic elements, look-up tables, and the like, 
which may carry out a variety of functions under the con- 
trol of one or more microprocessors or other control de- 
vices. Similarly, the software elements of the present in- 
vention may be implemented with any programming or 
scripting language such as C, C+ + , Java, COBOL, assem- 
bler, PERL, or the like, with the various algorithms being 
implemented with any combination of data structures, ob- 
jects, processes, routines or other programming ele- 
ments. Further, it should be noted that the present inven- 
tion may employ any number of conventional techniques 
for data transmission, signaling, data processing, network 
control, and the like. For a basic introduction to cryptog- 
raphy, see "Applied Cryptography: Protocols, Algorithms, 
And Source Code In C," written by Bruce Schneider pub- 
lished by John Wiley & Sons (second edition, 1996), which 
is hereby incorporated by reference. 



[0022] it should be appreciated that the particular implementa- 
tions shown and described herein are illustrative of the 
invention and its best mode and are not intended to oth- 
erwise limit the scope of the present invention in anyway. 
Indeed, for the sake of brevity, conventional data net- 
working, application development, and other functional 
aspects of the systems (and components of the individual 
operating components of the systems) may not be de- 
scribed in detail herein. Furthermore, the connecting lines 
shown in the various figures contained herein are in- 
tended to represent exemplary functional relationships 
and/or physical couplings between the various elements. 
It should be noted that many alternative or additional 
functional relationships or physical connections may be 
present in a practical electronic transaction system. It 
should further be noted that the order of the steps de- 
noted in the attached drawings are not intended as limita- 
tions and the steps may be accomplished in other orders 
without deviating from the scope of the present invention. 
Still further, the actors denoted as performing individual 
steps in the disclosed process should not be interpreted 
as limiting in any way as one with ordinary skill in the art 
appreciates that the steps may be performed by actors 



different from those disclosed herein without deviating 
from the spirit and scope of the present invention. 
[0023] it w i|| be appreciated that many applications of the 

present invention could be formulated. One skilled in the 
art will appreciate that the network may include any sys- 
tem for exchanging data or transacting business, such as 
the Internet, an intranet, an extranet, WAN, LAN, satellite 
communications, and/or the like. The parties may interact 
with the system via any input device such as a keyboard, 
mouse, kiosk, personal digital assistant, handheld com- 
puter (e.g., Palm Pilot®), cellular phone, and/or the like. 
Similarly, the invention could be used in conjunction with 
any type of personal computer, network computer, work- 
station, minicomputer, mainframe, or the like running any 
operating system such as any version of Windows, Win- 
dows NT, Windows 2000, Windows 98, Windows 95, Ma- 
cOS, OS/2, BeOS, Linux, UNIX, or the like. Moreover, al- 
though the invention may be implemented with TCP/IP 
communications protocols, it will be readily understood 
that the invention could also be implemented using IPX, 
Appletalk, IP-6, NetBIOS, OSI, or any number of existing 
or future protocols. Moreover, the system contemplates 
the use, sale, or distribution of any goods, services, or in- 



formation over any network having similar functionality 
described herein. 

[0024] The consumer, merchant, primary party, and service part- 
ner may represent individual people, entities, or busi- 
nesses. Although labeled as a "primary party," the primary 
party may represent other types of card issuing institu- 
tions, such as credit card companies, banks, card spon- 
soring companies, loyalty/incentive companies or third 
party issuers under contract with financial institutions. It 
is further noted that other participants may be involved in 
some phases of the system and methods, but these par- 
ticipants are not shown. Moreover, although many of the 
embodiments will be discussed with respect to trans- 
portation services, one skilled in the art will appreciate 
that the invention contemplates any other services or 
partners, such as, for example, entry to various trans- 
portation services (e.g., public transportation such as 
subways, buses and trains), access to a membership club, 
entry to an access-restricted location, access to credit 
services, telephone system use, and accrual of loyalty. 

[0025] Additionally, although many of the embodiments be dis- 
cussed with respect to a single, multi-service "card", as 
used herein, one skilled in the art will appreciate that the 



invention contemplates any other type of device or sys- 
tem, such as, for example, a card, transponder, fob, code, 
rewards card, charge card, credit card, debit card, prepaid 
card, telephone card, smart card, magnetic stripe card, 
bar code card, radio frequency card and/or other access 
device. The card may include one or more magnetic 
stripes, bar code and/or other information technology. 
For example, the card may include two magnetic stripes 
on one side, one magnetic stripe on the front and one 
magnetic stripe on the back, a card with multiple faces 
(e.g., telescopic, expanding or hinged card) and/or the 
like. The transponder or code may access multiple ac- 
counts related to the primary party and service partner, 
respectively. For example, see U.S. Serial No. 10/608,792, 
filed on June 27, 2003, by O'Malley, et al., and entitled 
"Method And Apparatus For Enrolling With Multiple Trans- 
action Environments", which is hereby incorporated by 
reference. The "card" may also not include a physical card 
or other device; rather, the "card", as used herein, may 
simply be an account or account number. Additionally, a 
"cardholder" or "consumer" includes any person or entity 
that uses a consumer card and participates in the present 
system and may include a person who is simply in pos- 



session of a financial account identifier, such as an autho- 
rization or account code. 

[0026] | n one embodiment, a consumer 108 may be provided 
with a single card that serves as both a credit card and a 
transportation card for access to the service partner's 
transportation services. This multiple-service card may 
have the traditional credit card data on one side of the 
card, including, for example, the account number, name 
of the account holder, and the expiration date. The other 
side of the card may include a magnetic stripe that con- 
tains the account information in machine readable form, a 
space for a signature, a consumer service number, a ser- 
vice partner transportation serial number that is suitable 
to permit entry to a service partner's services or facility, a 
barcode with the same transportation information and 
that may be scanned at the point of sale, and a photo- 
graph or a digital image or another identifying image of 
the card holder. The photograph or other identifying im- 
age may be taken at the service partner's location. Any 
combinations of the foregoing data may be located on ei- 
ther side of the card. 

[0027] The card may also be associated with an account or ac- 
count number, wherein an "account" or "account number", 



as used herein, may include any device, code, number, 
letter, symbol, digital certificate, smart chip, digital signal, 
analog signal, biometric or other identifier/indicia suitably 
configured to allow the consumer to access, interact with 
or communicate with the system such as, for example, 
one or more of an authorization/access code, personal 
identification number (PIN), Internet code, other identifi- 
cation code, and/or the like. The account number may be 
distributed and stored in any form of plastic, electronic, 
magnetic, radio frequency, wireless, audio and/or optical 
device capable of transmitting or downloading data from 
itself to a second device. A consumer account number 
may be, for example, a sixteen-digit credit card number, 
although each credit provider has its own numbering sys- 
tem, such as the fifteen-digit numbering system used by 
American Express. Each company's credit card numbers 
comply with that company's standardized format such 
that the company using a sixteen-digit format will gener- 
ally use four spaced sets of numbers, as represented by 
the number "0000 0000 0000 0000". The first five to 
seven digits are reserved for processing purposes and 
identify the issuing bank, card type, etc. In this example, 
the last (sixteenth) digit is used as a sum check for the 



sixteen-digit number. The intermediary eight-to-ten dig- 
its are used to uniquely identify the consumer. A mer- 
chant account number may be, for example, any number 
or alpha-numeric characters that identifies a particular 
merchant for purposes of card acceptance, account rec- 
onciliation, reporting, or the like. 
[0028] Because the card may access combined services such as 
financial transaction services and transportation services, 
the system may facilitate charging the financial account 
for the transportation services. In this regard, upon using 
the card to access a transportation service, the system 
may also access the financial account and deduct the cost 
of the transportation service from the financial account. In 
one embodiment, the transaction may occur like a known 
point of sale retail purchase transaction. The deduction 
may be in substantially real-time, batch mode, periodi- 
cally, upon request, based on an algorithm or any other 
routine. The system may allow the consumer to use loy- 
alty points or geographic based loyalty points to pay for 
the transportation services. In this regard, the system may 
"convert" the loyalty points to a currency value. For more 
information related to converting loyalty points to a cur- 
rency value, see, for example, U.S. Serial No. 09/834,478, 



filed on April 13, 2001, by Chien, et al., and entitled "Sys- 
tem and Method for Using Loyalty Points," which is hereby 
incorporated by reference. The system may also limit the 
use of certain loyalty points based upon the geographic 
area for certain transportation services in certain geo- 
graphic areas (as described below). 

[0029] As illustrated in Fig. 1, in an exemplary embodiment, the 
system may include a primary party 102 provider of credit 
services as well as a service partner 106. Both the primary 
party 102 and the service partner 106 are equipped with a 
computing unit or system to facilitate online commerce 
transactions and communications. These computing units 
or systems may take the form of a computer or set of 
computers, although other types of computing units or 
systems may be used, including laptops, notebooks, hand 
held computers, set-top boxes, workstations, computer- 
servers, main frame computers, mini-computers, PC 
servers, network sets of computers, and/or the like. 

[0030] The primary party 102 and the service partner 106 both 
comprise computing units or systems, which may com- 
municate with and through a card service engine 104, and 
all of which are connected with each other via a data com- 
munication network. The network may be a public net- 



work, which should be assumed to be insecure and open 
to eavesdroppers. For example, the internet may be em- 
ployed as the network. In this context, the computers may 
or may not be connected to the Internet at all times. For 
instance, the service partner 106 computer may employ a 
modem to occasionally connect to the Internet, whereas 
the primary party's computing center might maintain a 
permanent connection to the Internet. It is noted that the 
network may also be implemented as other types of net- 
works, such as an interactive television (ITV) network. The 
computers may also be interconnected via existing pro- 
prietary networks such as those that presently accommo- 
date transactions for credit cards, debit cards, and other 
types of financial/banking cards. Such an interconnection 
is a closed network that may be assumed to be secure 
from eavesdroppers. Examples of these proprietary net- 
works include the American Express®, VisaNet®, and the 
Veriphone® networks. 
[0031] | n general, in an exemplary embodiment, the multiple-ser- 
vice card is a credit card co-branded with a service part- 
ner transportation card. In one embodiment, a prospective 
consumer 108 provides the service partner 106 with ap- 
plication information for both the primary party's services 



and a service partner's services. Such information may in- 
clude, for example, traditional credit card application in- 
formation as well as traditional transportation application 
information. The service partner 106 collects and pro- 
cesses the application information, and forwards it to the 
primary party 102, via the card service engine 104, for 
further processing. The card service engine 104 approves 
or declines the new account, and returns the information 
to the service partner 106. The service partner 106, then, 
matches the approved accounts with the transportation 
applications it has previously processed. Finally, the ser- 
vice partner 106 sends its transportation information to a 
card generator 120, which fabricates the physical card and 
sends the card to the consumer 108. An example of the 
card fabrication process is found in U.S. Patent Application 
No. 09/653,837 entitled "Transaction Card" filed Septem- 
ber 1, 2000, the entire contents of which are herein incor- 
porated by reference. The invention also contemplates the 
application information being sent initially to the primary 
party or separately to the primary party and the trans- 
portation partner. 
[0032] | n one embodiment, the primary party 102 and the service 
partner 106 participants cooperate to complete the pro- 



cesses associated with the provision of the combined card 
services. Those processes may include a new account pro- 
cess, card replacement and renewal processes, a cancella- 
tion of transportation services process, and a process for 
cancellation and/or transfer by a primary party 102. The 
card replacement and renewal process may be initiated by 
the primary party 102 or the service partner 106 and may 
be a response to a member's request, a member's report- 
ing of fraudulent activity, an emergency, or the member's 
activity in association with a service partner 106. The sys- 
tem may also incorporate anti-terrorism software and de- 
vices to restrict access to financial accounts or transporta- 
tion services under certain conditions. Each of the process 
participants performs a series of process steps. 
[0033] The New Account Process: In an exemplary new account 
process, multiple process participants cooperate to ac- 
complish the process steps. The process participants may 
include only the primary party 102, the card service en- 
gine 104, and the service partner 106, but those partici- 
pants may also delegate their responsibilities to entities 
within their respective organizations or to other entities. 
Furthermore, the card service engine 104 may be the 
same party as either the primary party 102 or the service 



partner 106. Referring to Figs. 2a and 2b, regardless 
whether, or to which entities, the various process steps 
are delegated, the new account process is initiated by a 
consumer's submission of application information (step 
210) to either the service partner 106 or the primary party 
102. If the consumer 108 submits the information to the 
service partner 106, the service partner 106 may route the 
information to the primary party or the service partner 
may perform the initial processing of the application in- 
formation (step 220). If the consumer 108 submits the 
application information to the card service engine 104, 
however, the primary party 102 receives the application 
(step 210) from the consumer 108 and routes (step 210) 
the information to the service partner 106, which per- 
forms the initial processing (step 220). 
[0034] while the below steps may refer to the service partner en- 
rolling the consumer, the invention contemplates only 
certain of the disclosed enrollment steps or no enrollment 
by the service partner. For example, because the transac- 
tions for each of the service partner services may include 
minimal value (e.g., $1 bus fare), the service partner may 
not have a need or desire to complete a complicated en- 
rollment process. Moreover, the consumer may not want 



to disclose potentially private information to a public en- 
tity which operates the transportation services. In other 
embodiments, the consumer may already obtain a finan- 
cial transaction account and card, so the registration and 
processing may only relate to adding the transportation 
account to the pre-existing financial account. 

[0035] The initial processing (step 220) performed by the service 
partner 106 may include the steps of receiving (step 221) 
the application information, keying (step 222) each appli- 
cation information file for basic information, transferring 
(step 223) the application information into the service 
partner's database, creating (step 224) a unique applica- 
tion information file product control number for each ap- 
plication, creating (step 225) a standard variable byte file 
of new application data, and sending (step 226) the stan- 
dard variable byte file of new application data via batch 
process interface/Tl line to the card service engine 104. 
The unique product control number is also applied to any 
physical application, which is also sent to retention. In an 
exemplary embodiment, this file does not contain any 
service partner 106 data. 

[0036] As used herein, the term product control number refers to 
a number that identifies the primary party 102 and/or 



service partner 106 that keyed in the application and the 
date on which it was keyed. Also, as used herein, the term 
balancing report refers to a report that verifies and files 
information sent between two parties. Finally, the infor- 
mation administrator 112 records information, transfers 
files, and sends reports and other electronic communica- 
tion between the primary party 102 and a service partner 
106. 

[0037] | n addition to accomplishing the initial processing of new 
application information, the service partner 106 produces 
(step 230) a balancing report containing the total records 
of each file and transmits (step 231) the report to the pri- 
mary party 102. The service partner 106 also produces 
(step 232) a new account aging report of any applications 
greater than a predetermined period of time, for example, 
30 days. These reports are utilized by the information ad- 
ministrator 112 after each transmission. Finally, the ser- 
vice partner 106 returns (step 233) any paper applications 
and aligns (step 234) with the card service engine's reten- 
tion guidelines. 

[0038] Once the initial processing is complete, the card service 
engine 104 receives (step 240) the standard variable byte 
file from the service partner 106 and performs additional 



processing. This additional processing includes creating 
(step 241) necessary codes and updating (step 242) re- 
lated tables required to identify the new consumer and the 
service partner 106 products, creating (step 243) a con- 
solidated decisioning file, sending (step 244) an approved 
accounts file to the card service engine 104, processing 
(step 245) declined applications, updating (step 246) the 
balancing report containing total records of the transmit- 
ted file, creating (step 247) a job control language process 
to execute the information administrator balancing job, 
and creating (step 248) a back-up of the transmitted file 
and balancing reports in accordance with the card service 
engine's current standards. The consolidated decisioning 
file contains approved, declined, and cancelled service 
partner application information. 
[0039] The consumer service administrator 114 extracts (step 

250) all approved, declined, and cancelled service partner 
application information from the card service engine's 
consolidated decisioning file and transmits (step 251) a 
billing data file that is sorted, first by product control 
number and then by sequence number, to the service 
partner 106 containing data on approved, declined, and 
cancelled service partner accounts, excluding pending ap- 



plications. The consumer service administrator 114 also 
produces (step 252) a balancing report containing total 
records of the transmitted file and creates a job control 
language process to execute the information administra- 
tor balancing job after receiving the service partner's 
transmission report. Finally, the consumer service admin- 
istrator 114 creates (step 253) a back-up of the transmit- 
ted file and balancing report with an expiration of, for ex- 
ample, 90 days. 

[0040] with all declined or cancelled applications, the billing data 
file contains the transaction date, the product control 
number, the consumer's name, the sequence number, and 
the status code indicating whether the status is approved, 
declined, or cancelled. With all approved applications, the 
billing data file contains the transaction date, the primary 
party's account number (basic and supplemental), the 
product control number, the consumer's name, the se- 
quence number, and the status code indicating whether 
the status is approved, declined, or cancelled. 

[0041] Once the service partner 106 receives the billing data file 
that was transmitted by the consumer service administra- 
tor 114, the service partner 106 identifies (step 260) ap- 
proved accounts by the presence of an account number 



issued by the primary party 102 and populates (step 261) 
the service partner's database with the primary party's 
new account numbers. For any unrecognized product 
control numbers, the service partner 106 produces (step 
262) a reject report to be used for operations reconcilia- 
tion processes. This reject report includes the primary 
party's account number, if applicable, the consumer's 
name, the product control numbers, and the transaction 
date. The service partner 106 also produces (step 263) a 
balancing report containing total records of the received 
file and transmits (step 264) the report to the primary 
party 102. After receiving an approved account file from 
the card service engine 104, the card service engine 104 
loads (step 270) the file onto its database, creates (step 
271) a daily plastic file, and, periodically, sends (step 272) 
a plastic embossing file to the card generator 120. 
[0042] The card generator 120, receives (step 280), periodically, 
the plastic file from the card service engine 104. Upon re- 
ceipt of the plastic file, the card generator 120 identifies 
(step 281) all service partner charge and lending accounts 
on the primary party's renewal plastic file and transmits 
(step 282) an identified accounts file of all identified ac- 
counts to the service partner 106. The identified accounts 



file includes information such as the primary party's ac- 
count numbers, consumer 108 names, the card generator 
processing identifiers, transaction dates, and the primary 
party's bag Id's. A new identified accounts file is created 
periodically for renewal and periodic processing. Balanc- 
ing reports are also sent (step 283) to show the total 
number of accounts sent to the service partner 106. 

[0043] upon receipt of the identified accounts file from the card 
generator 120, the service partner 106 merges (step 290) 
the identified accounts file to the service partner 106 
database by the primary party's new account numbers. 
The service partner 106 periodically sorts (step 291) the 
daily file by approved, declined, and cancelled in numeric 
sequential order to create a daily transportation file with 
service partner 106 transportation information. Finally, 
the service partner 106 transmits (step 292) the daily 
transportation file to the card generator 120. 

[0044] For individual members, service partner 106 transporta- 
tion data includes, for example, the service partner num- 
ber, service partner member type, and a photo image. In 
general, other transportation data includes, for example, 
geographic data, loyalty information, a photo image flag 
indicator, the primary party's new account number, the 



card generator processing indicator, processing data, and 
the card generator bag-ID. 

[0045] After transmitting the daily file to the card generator 120, 
the service partner 106 creates (step 293) an exception 
reject report containing invalid product control numbers, 
which are account numbers that did not result in a match 
on the service partner database. The exception reject re- 
port is used with the operations reconciliation process and 
includes the primary party's account number, consumer 
name, transaction date, the card generator processing in- 
dicator, and the primary party 102 bag-ID. Finally, the 
service partner 106 produces (step 294) a balancing re- 
port containing the total records of the received identified 
accounts file. This balancing report is utilized by the in- 
formation administrator 112 after each transmission for 
balancing with the card generator 120. 

[0046] After receiving the updated embossing information file 
from the service partner 106, the card generator 120 
merges (step 284), using the primary party's new account 
number, the data from the updated embossing informa- 
tion file with the plastic file that was received previously 
from the card service engine 104. In addition, the card 
generator 120 embosses all required primary party 102 



data, prints a consumer number on the signature panel, 
prints applicable service partner transportation data such 
as that which is described above, on the back of the pri- 
mary party card, places the service partner transportation 
number in the third magnetic stripe position, converts the 
service partner transportation number to a bar code, 
prints the bar code on the back of the transportation card, 
and sends the transportation card to the consumer 108. 
[0047] | n addition, the card generator 120 creates (step 285) a 

reject report for all non-primary party account numbers or 
invalid card generator processing indicators received from 
the service partner 106. This reject report includes all 
data received on the service partner file except a photo 
image. The report is labeled "Invalid Accounts Received 
from Service Partner" and is used for operational reconcil- 
iation. 

[0048] Finally, the card generator 120 re-sends, in a subsequent 
transmission to the service partner 106, namely account 
numbers that do not have a service partner transportation 
number. After a predetermined number of attempts, the 
information is removed from the embossing file and 
placed on the card generator's reject report. Balancing re- 
ports show the total number of accounts received from 



the service partner 106. 
[0049] c arc | Replacement Processes: In an exemplary card re- 
placement process, multiple process participants cooper- 
ate to accomplish the process steps. The process partici- 
pants may include only the primary party 102, the card 
service engine 104, and the service partner 106, but those 
participants may also delegate their responsibilities to en- 
tities within their respective organizations or to other en- 
tities. Furthermore, the card service engine 104 may be 
the same party as either the primary party 102 or the ser- 
vice partner 106. Regardless to which entities the various 
process steps are delegated, the card replacement process 
may be initiated by the primary party 102, in conjunction 
with the consumer 108, or by the service partner 106. 
Further, special procedures may be called out in cases of 
fraud or emergency. In an exemplary embodiment, after 
initial processing, a plastic card replacement process is 
initiated. 

[0050] Referring to Fig's. 3a and 3b, if a consumer 108 requests 
(step 310) card replacement, the card replacement admin- 
istrator 116 updates (step 311) the plastic replacement 
request with the card service engine 104 and thereby ini- 
tiates the plastic card replacement process. If a consumer 



108 reports (step 320) fraudulent activity on an account, 
the report is sent (step 321) to the fraud resolution ad- 
ministrator 118, which attempts (step 322) to solve the 
case and, if the claim is deemed valid, sends (step 323) a 
request to the card replacement administrator 116, which 
updates (step 324) the plastic replacement request with 
the card service engine 104 and thereby initiates the plas- 
tic card replacement process. 
[0051] |f a consumer 108 requests (step 330) emergency card re- 
placement, the card replacement administrator 116 up- 
dates (step 331) the card service engine 104 to not issue a 
plastic card and updates the card server, which sends 
(step 332) embossing information to the card generator 
120, which embosses (step 333) the plastic and sends it 
to the consumer 108. In an exemplary embodiment, these 
emergency cards do not contain any service partner data 
and expire at the end of the following month unless oth- 
erwise requested by the consumer 108. In addition, the 
card replacement administrator 116 issues (step 334) a 
second request to the card service engine 104 to issue 
service partner replacement plastic, thereby initiating the 
standard card replacement process. In cases of emergency 
card replacement, the consumer 108 is notified (step 



335), first, that emergency card replacement plastic will 
preferably not contain service partner data and that the 
consumer 108 should seek assistance from the service 
partner help desk, second, that multiple-service card re- 
issuance will occur and will be received within a predeter- 
mined period of time, and third, that additional cards on 
the account may be required to be replaced if the service 
partner 106 determines that there are changes to trans- 
portation information. 

[0052] The service partner 106 may initiate card replacement by 
updating (step 340) the service partner data and sending 
(step 341) a file to the card replacement administrator 
116 indicating the consumers 108 who require new plas- 
tic cards. The service partner 106 also produces (step 
342) a balancing report containing the total records of the 
transmitted file and transmits the report to the primary 
party 102. This report is used by the information adminis- 
trator 112 after each transmission for balancing with the 
card generator 120. 

[0053] After receiving (step 350) the updated service partner data 
file from the service partner 106, the consumer service 
administrator 114 reads (step 351) the file and sends 
(step 352) a request to the card replacement administra- 



tor 116 to create replacement plastic cards. The consumer 
service administrator 114 also creates (step 353) a reject 
report with the card replacement administrator 116 indi- 
cating service partner replacements that have invalid ac- 
count numbers. Next, the consumer service administrator 
114 produces (step 354) a balancing report containing the 
total records of the transmitted/received file. The con- 
sumer service administrator 114 also creates (step 355) a 
job control language process to execute the information 
administrator's balancing job. Finally, the consumer ser- 
vice administrator 114 creates (step 356) a back-up of the 
service partner replacement request file and balancing re- 
ports for a predetermined period of time, for example, 90 
days. 

[0054] upon receipt (step 360) of the request from the consumer 
service administrator 114 to create replacement plastic 
cards, the card replacement administrator 116 updates 
(step 361) the plastic replacement request with the card 
service engine 104 and thereby initiates the plastic card 
replacement process. 

[0055] As previously stated, the plastic card replacement process 
is initiated by a party's updating the plastic replacement 
request with the card service engine 104. Upon receipt of 



such an update, the card service engine 104 creates (step 
370) a daily plastic file and sends (step 371) a daily plastic 
embossing file to the card generator 120. 

[0056] upon receipt (step 380) of the daily plastic embossing file 
from the card service engine 104, the card generator 120 
segments (step 381) service partner accounts and sends 
(step 382) a file of all identified service partner accounts 
to the service partner 106. This file is transmitted daily 
and contains the primary party's account number, the 
consumer's name, the card generator processing identi- 
fier, transaction date, and the primary party's bag ID. Sep- 
arate files are created for renewal and daily processing. 
Balancing reports are also sent (step 383) showing total 
number of accounts sent to the service partner 106. 

[0057] upon receipt (step 382) of the file showing all identified 
service partner accounts, the service partner 106 merges 
(step 384) the data contained in the file to the service 
partner database according to the primary party's new ac- 
count number. At this point, the service partner 106 may 
also need to determine (step 385) whether additional con- 
sumers 108 in the relationship require their cards to be 
replaced due to any changes in service partner trans- 
portation data. Next, the service partner 106 sorts (step 



386) the daily file by the basic cards first, then the sup- 
plemental cards, in numeric sequential order. In addition, 
the service partner 106 creates (step 387) an embossing 
information file with any new service partner transporta- 
tion data and transmits (step 388) the embossing infor- 
mation file to the card generator 120. The service partner 
106 also creates (step 389) an exception reject report for 
account numbers that did not result in a match on the 
service partner database. This report is for use with the 
operations reconciliation process and includes the primary 
party's account number, consumer's name, transaction 
date, the card generator processing indicator, and the pri- 
mary party bag-ID. Finally, the service partner produces a 
balancing report containing total records of the received 
file. 

[0058] upon receipt of the embossing information file from the 
service partner 106, the card generator 120 merges (step 
390) the data from the service partner's embossing infor- 
mation file with the daily plastic embossing file previously 
received from the card service engine 104. For new ac- 
count numbers that do not have a service partner trans- 
portation number, plastic cards will not be embossed. 
Next, the card generator 120 embosses (step 391) the 



plastic cards and sends (step 392) the replacement cards 
to the consumers 108. The card generator 120 also gen- 
erates (step 393) a reject report for all non-primary party 
account numbers or invalid card generator processing in- 
dicators received from the service partner 106. This report 
includes all data received on the service partner file ex- 
cept the photo image. The report is labeled "invalid ac- 
counts received from service partner," and the report is 
used for operational reconciliation. Finally, the card gen- 
erator 120 re-sends (step 394) to the service partner ac- 
count numbers that did not have a service partner trans- 
portation number. These account numbers are sent in a 
subsequent transmission. After a predetermined number 
of attempts, the information is removed (step 395) from 
the embossing file and placed on the PDR reject report. 
[0059] c arc | Maintenance Pocesses/Service Partner Cancellation: 
In an exemplary service partner cancellation process, mul- 
tiple process participants cooperate to accomplish the 
process steps. The process participants may include only 
the primary party 102, the card service engine 104, and 
the service partner 106, but those participants may also 
delegate their responsibilities to entities within their re- 
spective organizations or to other entities. Furthermore, 



the card service engine 104 may be the same party as ei- 
ther the primary party 102 or the service partner 106. Re- 
ferring to Fig. 4, regardless to which entities the various 
process steps are delegated, the service partner cancella- 
tion process is initiated by the service partner 106, which 
transmits (step 410) a cancellation file to the primary 
party 102. The cancellation file contains data elements for 
all the primary party 102 consumers 108 who have can- 
celled their services with the service partner. These data 
elements include the cancellation date, the primary party"' 
new account number, and the consumer'" name. 
[0060] upon receipt of the cancellation file from the service part- 
ner 106, the primary party 102 produces (step 420) a ser- 
vice partner cancellation report on the report generator. 
This report is used by card service providers to transfer 
(step 430) consumers 108 to a new product. The primary 
party 102 also sends (step 421) a report to the consumer 
service administrator 114 and produces (step 422) a bal- 
ancing report containing total records of the received can- 
cellation file. In addition, the primary party 102 creates 
(step 423) a job control language process to execute the 
information administrator balancing job. Finally, the pri- 
mary party 102 creates (step 424) a backup of the service 



partner"' cancellation file and balancing reports for 90 
days. 

[0061] c arc | Maintenance Processes/Primary Party Consumer 
Cancellations or Transfers to non-Service Partner Prod- 
ucts: In an exemplary consumer cancellation process, 
multiple process participants cooperate to accomplish the 
process steps. The process participants may include only 
the primary party 102, the card service engine 104, and 
the service partner 106, but those participants may also 
delegate their responsibilities to entities within their re- 
spective organizations or to other entities. Furthermore, 
the card service engine 104 may be the same party as ei- 
ther the primary party 102 or the service partner 106. Re- 
ferring to Figs. 5a and 5b, regardless to which entities the 
various process steps are delegated, the consumer can- 
cellation process is initiated by the primary party"' con- 
sumer service administrator"' 114 receiving (step 510) a 
request from a consumer 108 to terminate or convert to 
another product. 

[0062] |f the consumer 108 requests not to terminate, and the 
consumer 108 specifies a product or transportation ser- 
vice, to which the consumer 108 wants to transfer, the 
consumer service administrator 114 opens (step 520) a 



memo queue and inserts (step 521) a notation indicating 
that the consumer 108 wants to transfer to a specific 
product or transportation service. In addition, the con- 
sumer service administrator 114 opens (step 522) a memo 
list and obtains (step 523) accounts that must be trans- 
ferred to a new IA. Finally, the consumer service adminis- 
trator 114 processes (step 524) the advancement of the 
rebate and performs the migration transaction to move 
the consumer 108 to the new product. 
[0063] if the consumer 108 wants to terminate, or if the con- 
sumer 108 fails to specify a product or transportation ser- 
vice, to which the consumer 108 wants to transfer, the 
consumer service administrator 114 dial transfers (step 
530) the consumer 108 to the transportation administra- 
tor, which verifies (step 531) that the consumer 108 wants 
to terminate. 

[0064] |f the consumer"' desire to terminate cannot be verified, 

the transportation administrator identifies (step 540) con- 
sumer transfer options and opens (step 541) a memo 
queue specifying the product, to which the consumer 108 
wants to transfer. In addition, the consumer service ad- 
ministrator 114 opens (step 542) a memo list and obtains 
(step 543) accounts that must be transferred to a new IA. 



Finally, the consumer service administrator 114 processes 
(step 544) the advancement of the rebate and performs 
(step 545) the migration transaction to move the con- 
sumer 108 to the new IA. 

[0065] if the consumer"' 108 desire to terminate is verified, the 
transportation administrator processes (step 550) the at- 
trition, causing the card service engine 104 to update 
(step 551) the file with a cancel code. In addition, the card 
service engine 104 creates (step 552) and/or updates 
(step 553) the change/renewal file with the transfer code 
for extraction by the consumer service administrator 114. 

[0066] Once the consumer service administrator 114 has ex- 
tracted (step 560) service partner/primary party accounts 
from the change/renewal file, the consumer service ad- 
ministrator 114 creates (step 561) a cancellation file of all 
consumers 108 who have cancelled their multiple-service 
card. Next, the consumer service administrator 114 trans- 
mits (step 562) the cancellation file to the service partner 
106 and produces (step 563) a primary party/service part- 
ner co-brand card cancellation report on the report gen- 
erator. This report will be utilized by card provider ser- 
vices to transfer (step 570) consumers 108 to a new pri- 
mary party product. The consumer service administrator 



114 also produces (step 571) a balancing report contain- 
ing total records of the transmitted file and creates (step 
572) a job control language process to execute the infor- 
mation administrator balancing job. Finally, the primary 
party 102 creates (step 573) a backup of the service part- 
ner cancellation file and balancing reports for 90 days. 

[0067] upon receipt (step 580) of the primary party"' cancellation 
file from the consumer service administrator 114, the ser- 
vice partner 106 turns the credit flag indicator to N, 
thereby severing (step 581) the system linkage. In this sit- 
uation, the service partner 106 may issue (step 582) a 
stand alone transportation card. Finally, the service part- 
ner 106 produces (step 583) a balancing report containing 
the total records of the transmitted file. This balancing re- 
port will be utilized (step 584) by the information admin- 
istrator 112 after each transmission for balancing with the 
card generator 120. 

[0068] As one skilled in the art will appreciate, the above de- 
scribed transaction entry interface, as well as any or all 
other aspects of the present invention, may include any 
suitable form of encryption and/or other security mea- 
sures either currently known or hereafter devised. 

[0069] The invention also includes a system and method for fa- 



cilitating a loyalty system which is associated with geo- 
graphic locations and/or services and goods offered in a 
specific geographic area. In this regard, the loyalty points 
may be used to pay for the transportation services in a 
particular geographic area. In different embodiments, the 
loyalty points may be earned within a specific geographic 
location, then redeemed in one geographic location, a 
subset of locations or without restrictions. Similarly, the 
loyalty points may be earned in one geographic location, a 
subset of locations or without restrictions, then redeemed 
only in a specific geographic location. Details of the loy- 
alty point earn and redemption process will be described 
in more detail below. Interaction with the system may in- 
clude communication to consumer service representatives, 
entry into webpages or any of the computing devices set 
forth herein. The financial or loyalty accounts may or may 
not be associated with any of the transaction accounts or 
cards set forth below. 
[0070] The geographic features of the system may be imple- 
mented using new types of data collected during the 
transaction or using existing data that is typically col- 
lected in a transaction, wherein the existing data may also 
be associated with geographic areas such as, for example, 



zip codes, retailer identification codes, service establish- 
ment codes, SKU codes, UPC manufacturer codes and/or 
the like. The collected information may be associated with 
any previously known information to perform data analy- 
sis related to the loyalty program on a local or network 
level (described in more detail below). 
[0071] The geographic area information may be associated with 
the consumer, merchant, processing system and/or any 
other part of the overall system. For example, a consumer 
may have a home zip code in New Jersey with a work zip 
code in New York City, so the system may determine that 
the consumer still qualifies for reward points from mer- 
chants with zip codes based in New York City. The system 
may also determine that a "double point" promotion may 
apply to purchases of products originating from manufac- 
turers in Tennessee. In a more complex embodiment, the 
system may encourage New Jersey residents to shop for 
soap products from an Arizona manufacturer (e.g., Dial 
Corporation) which are sold by a New York merchant. As 
such, the system may acquire, utilize and/or associate the 
consumer home zip code, the merchant building zip code, 
and the SKU information from the soap. In another em- 
bodiment, the rewards may have a theme related to the 



city. For example, New Orleans awards may be related to 
Jazz shows and Mardi Gras activities, while New York City 
awards may be related to Broadway shows, dining and 
other entertainment or sports venues. The awards may 
also include full geographic "experiences" such as, for ex- 
ample, dinner, backstage passes, cocktails with the cast, 
and movie premiers. 
[0072] The system may include online interfaces, dial-up inter- 
faces through POS terminals or any of the other hardware, 
software and communications discussed herein. In one 
embodiment, the system is configured with one product 
platform with a modularized approach to facilitate the de- 
velopment of market specific rewards and communication 
materials. Particularly, any geographic location and asso- 
ciated merchants may be input into aversion of the 
present invention such that the invention facilitates simi- 
lar features and functions in any newly created geographic 
region. For example, the system may be fully functional 
with various merchants, rewards and residents in the 
Manhattan, New York area. Different data may be inputted 
into the same system in order to facilitate similar func- 
tionality in the Phoenix, Arizona area, along with creating 
rewards and marketing material related to Phoenix mer- 



chants. In this regard, a participant may use a particular 
ID or password to access the system online, wherein the 
particular ID instructs the system to provide functions and 
marketing materials or displays related to the appropriate 
geographical region. For example, inputting ID #1234 into 
a web site may result in a web page displaying various re- 
wards redeemable at various Manhattan merchants. Simi- 
larly, inputting ID #5678 into the same web site may re- 
sult in a web page displaying various rewards redeemable 
at various Phoenix merchants. 
[0073] The present invention also includes facilitating the trans- 
fer of geographic area loyalty points between accounts. In 
an exemplary embodiment, the invention includes facili- 
tating the substantially real-time transfer of geographic 
area loyalty points between accounts. While the invention 
will be discussed in terms of a general transfer of geo- 
graphic area loyalty points, one skilled in the art will ap- 
preciate that the transfer may include a deduction from a 
first account and a crediting of a second account. More- 
over, the transfer may involve any portion of the points 
transferred in real-time, certain points transferred in a 
batch transfer, certain points transferred upon a trigger- 
ing event, certain points transferred over time and/or cer- 



tain points transferred upon satisfaction of a condition or 
rule. 

[0074] | n one embodiment, the system includes any hardware 
and/or software discussed herein or known in the art 
suitably configured for receiving a transfer request (e.g., 
consumer request, triggering event, etc) for a transfer of a 
any portion of geographic area loyalty points, accessing 
and analyzing the total number of loyalty points in the 
transferor account related to a particular geographic area 
to determine if a sufficient number of points exist, ana- 
lyzing the type/level of consumer and type/level of points 
(including geographic area associated with the points) to 
be involved in the transfer, determining if any rules exist 
for restricting or limiting the transfer of points (e.g., only 
transfer points to an account having other points in a par- 
ticular geographic area), using a conversion engine to 
convert the point value to an appropriate point value in 
the transferee account, deducting the requested loyalty 
points from the transferor account, and increasing the 
point balance in the transferee account. 

[0075] | n accordance with the present invention, geographic area 
loyalty points associated with a certain loyalty system may 
be transferred to other loyalty point accounts within the 



same loyalty system or to a loyalty point account in any 
other loyalty point system. For example, Hilton Reward 
points may be transferred to a United Airlines frequent 
flyer account. In one embodiment, a conversion engine fa- 
cilitates any point value conversions that may be appro- 
priate. For example, if a consumer desires to transfer five 
hundred Hilton Reward points to a United Airlines fre- 
quent flyer account, the conversion engine may determine 
that the five hundred Hilton Rewards points only translate 
into one hundred United Airlines frequent flyer points. As 
such, the system would only increase the United Airlines 
frequent flyer account by one hundred points. The rules or 
formulas associated with the conversion engine may be 
pre-established by the loyalty point system hosts. The 
transfer of any portion of loyalty points in a consumer ac- 
count may be initiated upon a triggering event such as, 
for example, a request by the transferor, a request by a 
transferee, a request by a loyalty system host, a request 
by a third party, a transfer on a certain date or time, a 
percentage of points transferred during certain time peri- 
ods and/or an automatic transfer upon a pre-established 
condition or data point. The transfer may also include 
certain conditions that must be met prior to, during and/ 



or after the transfer. If certain conditions are not met, the 
transfer may be voided or expire and/or any portion of 
the loyalty points may be returned to the original trans- 
feror, to the loyalty system, to another consumer loyalty 
account or to any other third party. For example, after re- 
ceiving transferred loyalty points, if the transferee does 
not earn a certain amount of loyalty points on her own in 
a certain geographic area, the transferred loyalty points 
are transferred to another supplementary member. The 
system may also credit any portion of the loyalty points to 
one or more loyalty point accounts, wherein any geo- 
graphic area restrictions may or may not apply. For exam- 
ple, the consumer may request that the loyalty points be 
transferred to an account associated with a family mem- 
ber, a friend, a charitable organization and/or the like. 
[0076] The transaction card of the present invention may also in- 
clude a dual purpose transaction device which combines 
geographic-based loyalty functionality, financial transac- 
tion functionality (e.g., charge card) and access function- 
ality (e.g., access to public transportation, including pay- 
ment of the transportation fare). The card may include 
one or more magnetic stripes related to each functional- 
ity. The card or other transponder device may alternatively 



include two different RFID signals for each functionality. 

[0077] As used herein, a "geographic area" or similar terms may 
include all or any portion of any street, city, county, state, 
country, continent, region (e.g., SoHo district, Chinatown), 
or any other areas, including combinations or subsets of 
areas. The geographic areas may relate to any of the par- 
ticipants, products, services or identifications. The geo- 
graphic areas may relate to any associated geographic 
area such as, for example, a geographic area associated 
with a participant's home residence, work residence, travel 
areas or the like. The geographic area may also be auto- 
matically established based on the geographic area where 
a participant is located at the time (or at any established 
time period) based on, for example, cellular phone caller 
location relative to cellular towers or a global positioning 
system. The geographic areas may also be associated with 
where the product is manufactured, distributed, sold or 
the like. Moreover, while certain embodiments may refer 
to only a specific geographic area for brevity, the inven- 
tion also contemplates other similar embodiments for 
multiple geographic areas or subsets of areas. 

[0078] The various system components discussed herein may in- 
clude one or more of the following: a host server or other 



computing systems including a processor for processing 
digital data; a memory coupled to said processor for stor- 
ing digital data; an input digitizer coupled to the proces- 
sor for inputting digital data; an application program 
stored in said memory and accessible by said processor 
for directing processing of digital data by said processor; 
a display device coupled to the processor and memory for 
displaying information derived from digital data processed 
by said processor; and a plurality of databases. Various 
databases used herein may include: client data; merchant 
data; financial institution data; and/or like data useful in 
the operation of the present invention. As those skilled in 
the art will appreciate, user computer may include an op- 
erating system (e.g., Windows NT, 95/98/2000, OS2, 
UNIX, Linux, Solaris, MacOS, etc.) as well as various con- 
ventional support software and drivers typically associated 
with computers. User computer can be in a home or busi- 
ness environment with access to a network. In an exem- 
plary embodiment, access is through a network or the In- 
ternet through a commercially-available web-browser 
software package. 
[0079] As used herein, the term "network" shall include any elec- 
tronic communications means which incorporates both 



hardware and software components of such. Communica- 
tion among the parties in accordance with the present in- 
vention may be accomplished through any suitable com- 
munication channels, such as, for example, a telephone 
network, an extranet, an intranet, Internet, point of inter- 
action device (point of sale device, personal digital assis- 
tant, cellular phone, kiosk, etc.), online communications, 
off-line communications, wireless communications, 
transponder communications, local area network (LAN), 
wide area network (WAN), networked or linked devices 
and/or the like. Moreover, although the invention is fre- 
quently described herein as being implemented with TCP/ 
IP communications protocols, the invention may also be 
implemented using IPX, Appletalk, IP-6, NetBIOS, OSI or 
any number of existing or future protocols. If the network 
is in the nature of a public network, such as the Internet, 
it may be advantageous to presume the network to be in- 
secure and open to eavesdroppers. Specific information 
related to the protocols, standards, and application soft- 
ware utilized in connection with the Internet is generally 
known to those skilled in the art and, as such, need not be 
detailed herein. See, for example, Dilip Naik, "Internet 
Standards and Protocols" (1998); "Java 2 Complete", vari- 



ous authors, (Sybex 1999); Deborah Ray and Eric Ray, 
"Mastering HTML 4.0" (1997); and Loshin, "TCP/IP Clearly 
Explained" (1997) and David Courley and Brian Totty, 
"HTTP, The Definitive Guide"( 2002), the contents of which 
are hereby incorporated by reference. 
[0080] The various system components may be independently, 
separately or collectively suitably coupled to the network 
via data links which includes, for example, a connection to 
an Internet Service Provider (ISP) over the local loop as is 
typically used in connection with standard modem com- 
munication, cable modem, Dish networks, ISDN, Digital 
Subscriber Line (DSL), or various wireless communication 
methods. See, e.g., Gilbert Held, "Understanding Data 
Communications" (1996), hereby incorporated by refer- 
ence. It is noted that the network may be implemented as 
other types of networks, such as an interactive television 
(ITV) network. Moreover, the system contemplates the 
use, sale or distribution of any goods, services or infor- 
mation over any network having similar functionality de- 
scribed herein. 

[0081] Any databases discussed herein may be any type of 

database, such as relational, hierarchical, graphical, ob- 
ject-oriented, and/or other database configurations. 



Common database products that may be used to imple- 
ment the databases include DB2 by IBM (White Plains, NY), 
various database products available from Oracle Corpora- 
tion (Redwood Shores, CA), Microsoft Access or Microsoft 
SQL Server by Microsoft Corporation (Redmond, Washing- 
ton), or any other suitable database product. Moreover, 
the databases may be organized in any suitable manner, 
for example, as data tables or lookup tables. Each record 
may be a single file, a series of files, a linked series of 
data fields or any other data structure. Association of cer- 
tain data may be accomplished through any desired data 
association technique such as those known or practiced in 
the art. For example, the association may be accom- 
plished either manually or automatically. Automatic asso- 
ciation techniques may include, for example, a database 
search, a database merge, GREP, ACREP, SQL, and/or the 
like. The association step may be accomplished by a 
database merge function, for example, using a "key field"! 
n pre-selected databases or data sectors. 
[0082] More particularly, a "key field"p artitions the database ac- 
cording to the high-level class of objects defined by the 
key field. For example, certain types of data may be des- 
ignated as a key field in a plurality of related data tables 



and the data tables may then be linked on the basis of the 
type of data in the key field. In this regard, the data corre- 
sponding to the key field in each of the linked data tables 
is preferably the same or of the same type. However, data 
tables having similar, though not identical, data in the key 
fields may also be linked by using AGREP, for example. In 
accordance with one aspect of the present invention, any 
suitable data storage technique may be utilized to store 
data without a standard format. Data sets may be stored 
using any suitable technique, including, for example, 
storing individual files using an ISO/IEC 7816-4 file struc- 
ture; implementing a domain whereby a dedicated file is 
selected that exposes one or more elementary files con- 
taining one or more data sets; using data sets stored in 
individual files using a hierarchical filing system; data sets 
stored as records in a single file (including compression, 
SQL accessible, hashed via one or more keys, numeric, al- 
phabetical by first tuple, etc.); block of binary (BLOB); 
stored as ungrouped data elements encoded using ISO/ 
IEC 7816-6 data elements; stored as ungrouped data ele- 
ments encoded using ISO/IEC Abstract Syntax Notation 
(ASN.l) as in ISO/IEC 8824 and 8825; and/or other pro- 
prietary techniques that may include fractal compression 



methods, image compression methods, etc. 
[0083] | n one exemplary embodiment, the ability to store a wide 
variety of information in different formats is facilitated by 
storing the information as a Block of Binary (BLOB). Thus, 
any binary information can be stored in a storage space 
associated with a data set. As discussed above, the binary 
information may be stored on the financial transaction in- 
strument or external to but affiliated with the financial 
transaction instrument. The BLOB method may store data 
sets as ungrouped data elements formatted as a block of 
binary via a fixed memory offset using either fixed stor- 
age allocation, circular queue techniques, or best prac- 
tices with respect to memory management ((e.g., paged 
memory, least recently used, etc.). By using BLOB meth- 
ods, the ability to store various data sets that have differ- 
ent formats facilitates the storage of data associated with 
the financial transaction instrument by multiple and unre- 
lated owners of the data sets. For example, a first data set 
which may be stored may be provided by a first issuer, a 
second data set which may be stored may be provided by 
an unrelated second issuer, and yet a third data set which 
may be stored, may be provided by an third issuer unre- 
lated to the first and second issuer. Each of these three 



exemplary data sets may contain different information 
that is stored using different data storage formats and/or 
techniques. Further, each data set may contain subsets of 
data which also may be distinct from other subsets. 
[0084] As stated above, in various embodiments of the present 
invention, the data can be stored without regard to a 
common format. However, in one exemplary embodiment 
of the present invention, the data set ((e.g., BLOB) may be 
annotated in a standard manner when provided for ma- 
nipulating the data onto the financial transaction instru- 
ment. The annotation may comprise a short header, 
trailer, or other appropriate indicator related to each data 
set that is configured to convey information useful in 
managing the various data sets. For example, the annota- 
tion may be called a "condition header", "header", "trailer", 
or "status", herein, and may comprise an indication of the 
status of the data set or may include an identifier corre- 
lated to a specific issuer or owner of the data. In one ex- 
ample, the first three bytes of each data set BLOB may be 
configured or configurable to indicate the status of that 
particular data set; e.g., LOADED, INITIALIZED, READY, 
BLOCKED, REMOVABLE, or DELETED. Subsequent bytes of 
data may be used to indicate for example, the identity of 



the issuer, user, transaction/membership account identi- 
fier or the like. Each of these condition annotations are 
further discussed herein. 

[0085] The data set annotation may also be used for other types 
of status information as well as various other purposes. 
For example, the data set annotation may include security 
information establishing access levels. The access levels 
may, for example, be configured to permit only certain in- 
dividuals, levels of employees, companies, or other enti- 
ties to access data sets, or to permit access to specific 
data sets based on the transaction, merchant, issuer, user 
or the like. Furthermore, the security information may re- 
strict/permit only certain actions such as accessing, mod- 
ifying, and/or deleting data sets. In one example, the data 
set annotation indicates that only the data set owner or 
the user are permitted to delete a data set, various identi- 
fied merchants are permitted to access the data set for 
reading, and others are altogether excluded from access- 
ing the data set. However, other access restriction param- 
eters may also be used allowing various entities to access 
a data set with various permission levels as appropriate. 

[0086] The data, including the header or trailer may be received 
by a stand alone interaction device configured to add, 



delete, modify, or augment the data in accordance with 
the header or trailer. As such, in one embodiment, the 
header or trailer is not stored on the transaction device 
along with the associated issuer-owned data but instead 
the appropriate action may be taken by providing to the 
transaction instrument user at the stand alone device, the 
appropriate option for the action to be taken. The present 
invention may contemplate a data storage arrangement 
wherein the header or trailer, or header or trailer history, 
of the data is stored on the transaction instrument in rela- 
tion to the appropriate data. 

[0087] one skilled in the art will also appreciate that, for security 
reasons, any databases, systems, devices, servers or other 
components of the present invention may consist of any 
combination thereof at a single location or at multiple lo- 
cations, wherein each database or system includes any of 
various suitable security features, such as firewalls, access 
codes, encryption, decryption, compression, decompres- 
sion, and/or the like. 

[0088] The computers discussed herein may provide a suitable 
website or other Internet-based graphical user interface 
which is accessible by users. In one embodiment, the Mi- 
crosoft Internet Information Server (IIS), Microsoft Trans- 



action Server (MTS), and Microsoft SQL Server, are used in 
conjunction with the Microsoft operating system, Mi- 
crosoft NT web server software, a Microsoft SQL Server 
database system, and a Microsoft Commerce Server. Addi- 
tionally, components such as Access or Microsoft SQL 
Server, Oracle, Sybase, Informix MySQL, Interbase, etc., 
may be used to provide an Active Data Object (ADO) com- 
pliant database management system. 
[0089] Any of the communications, inputs, storage, databases or 
displays discussed herein may be facilitated through a 
website having web pages. The term "web page"a s it is 
used herein is not meant to limit the type of documents 
and applications that might be used to interact with the 
user. For example, a typical website might include, in ad- 
dition to standard HTML documents, various forms, Java 
applets, JavaScript, active server pages (ASP), common 
gateway interface scripts (CGI), extensible markup lan- 
guage (XML), dynamic HTML, cascading style sheets (CSS), 
helper applications, plug-ins, and the like. A server may 
include a web service which receives a request from a web 
server, the request including a URL 
(http://yahoo.com/stockquotes/ge) and an IP address 
(123.56.789). The web server retrieves the appropriate 



web pages and sends the data or applications for the web 
pages to the IP address. Web services are applications 
which are capable of interacting with other applications 
over a communications means, such as the internet. Web 
services are typically based on standards or protocols 
such as XML, SOAP, WSDL and UDDI. Web services meth- 
ods are well known in the art, and are covered in many 
standard texts. See, e.g., Alex Nghiem, "IT Web Services: A 
Roadmap for the Enterprise'^ 2003), hereby incorporated 
herein by reference. 
[0090] As will be appreciated by one of ordinary skill in the art, 
the present invention may be embodied as a method, a 
data processing system, a device for data processing, 
and/or a computer program product. Accordingly, the 
present invention may take the form of an entirely soft- 
ware embodiment, an entirely hardware embodiment, or 
an embodiment combining aspects of both software and 
hardware. Furthermore, the present invention may take 
the form of a computer program product on a computer- 
readable storage medium having computer-readable pro- 
gram code means embodied in the storage medium. Any 
suitable computer-readable storage medium may be uti- 
lized, including hard disks, CD-ROM, optical storage de- 



vices, magnetic storage devices, and/or the like. 

[0091] The present invention is described herein with reference 
to screen shots, block diagrams and flowchart illustrations 
of methods, apparatus ((e.g., systems), and computer 
program products according to various aspects of the in- 
vention. It will be understood that each functional block of 
the block diagrams and the flowchart illustrations, and 
combinations of functional blocks in the block diagrams 
and flowchart illustrations, respectively, can be imple- 
mented by computer program instructions. These com- 
puter program instructions may be loaded onto a general 
purpose computer, special purpose computer, or other 
programmable data processing apparatus to produce a 
machine, such that the instructions which execute on the 
computer or other programmable data processing appa- 
ratus create means for implementing the functions speci- 
fied in the flowchart block or blocks. 

[0092] These computer program instructions may also be stored 
in a computer-readable memory that can direct a com- 
puter or other programmable data processing apparatus 
to function in a particular manner, such that the instruc- 
tions stored in the computer-readable memory produce 
an article of manufacture including instruction means 



which implement the function specified in the flowchart 
block or blocks. The computer program instructions may 
also be loaded onto a computer or other programmable 
data processing apparatus to cause a series of operational 
steps to be performed on the computer or other pro- 
grammable apparatus to produce a computer-imple- 
mented process such that the instructions which execute 
on the computer or other programmable apparatus pro- 
vide steps for implementing the functions specified in the 
flowchart block or blocks. 
[0093] Accordingly, functional blocks of the block diagrams and 
flowchart illustrations support combinations of means for 
performing the specified functions, combinations of steps 
for performing the specified functions, and program in- 
struction means for performing the specified functions. It 
will also be understood that each functional block of the 
block diagrams and flowchart illustrations, and combina- 
tions of functional blocks in the block diagrams and 
flowchart illustrations, can be implemented by either spe- 
cial purpose hardware-based computer systems which 
perform the specified functions or steps, or suitable com- 
binations of special purpose hardware and computer in- 
structions. 



[0094] | t should be understood, however, that the detailed de- 
scription and specific examples, while indicating exem- 
plary embodiments of the present invention, are given for 
purposes of illustration only and not of limitation. Many 
changes and modifications within the scope of the instant 
invention may be made without departing from the spirit 
thereof, and the invention includes all such modifications. 
The corresponding structures, materials, acts, and equiv- 
alents of all elements in the claims below are intended to 
include any structure, material, or acts for performing the 
functions in combination with other claimed elements as 
specifically claimed. The scope of the invention should be 
determined by the appended claims and their legal equiv- 
alents, rather than by the examples given above. For ex- 
ample, the steps recited in any method claims may be ex- 
ecuted in any order and are not limited to the order pre- 
sented in the claims. Moreover, no element is essential to 
the practice of the invention unless specifically described 
herein as "criticaT'o r "essential". 



